OCPBUGS-45290: Reject All CA-Signed Certs Using SHA1 #642

gcs278 · 2024-12-04T02:33:19Z

Previously, only SHA1 leaf certs were rejected. However, in 4.16, any SHA1 cert that is CA-signed (not self-signed) is unsupported. This led to cases were routes with SHA1 intermediate CA certs were accepted, but HAProxy rejects them. Self-signed SHA1 certificates (i.e. root CA) remain supported since they are not subject to verification.

This update ensures all route certs, including the server, CA, and destination CA certs, are inspected, and any SHA1 cert that is not self-signed is rejected.

openshift-ci · 2024-12-04T02:33:23Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

openshift-ci-robot · 2024-12-04T02:33:24Z

@gcs278: This pull request references Jira Issue OCPBUGS-45290, which is invalid:

expected the bug to target the "4.19.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

Previously, we rejected leaf certs using SHA1, but we also need to reject intermediate CA certs using SHA1 as HAProxy fails to start.

WIP:
Needs clean up and unit tests.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

gcs278 · 2024-12-06T01:24:51Z

/retest

gcs278 · 2024-12-06T02:28:00Z

/jira refresh

openshift-ci-robot · 2024-12-06T02:28:07Z

@gcs278: This pull request references Jira Issue OCPBUGS-45290, which is invalid:

expected the bug to target the "4.19.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

gcs278 · 2024-12-06T02:28:39Z

/jira refresh

openshift-ci-robot · 2024-12-06T02:28:45Z

@gcs278: This pull request references Jira Issue OCPBUGS-45290, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target version (4.19.0) matches configured target version for branch (4.19.0)
bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @ShudiLi

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

ShudiLi · 2024-12-06T06:59:08Z

tested it with 4.18.0-0.ci.test-2024-12-06-060222-ci-ln-4l8tlmt-latest, same steps as the bug

% oc -n test get route                          
NAME           HOST/PORT                  PATH   SERVICES      PORT   TERMINATION   WILDCARD
test-sha1-ca   ExtendedValidationFailed          unsec-apach   8080   edge          None
% oc -n test get route -oyaml | grep -A5 status:
  status:
    ingress:
    - conditions:
      - lastTransitionTime: "2024-12-06T06:54:50Z"
        message: 'spec.tls.caCertificate: Invalid value: "redacted ca certificate
          data": router does not support CA-signed certs using SHA1'
--
        status: "False"
        type: Admitted
      host: test-sha1-ca.apps.example.com
      routerCanonicalHostname: router-default.apps.ci-ln-4l8tlmt-72292.gcp-2.ci.openshift.org
      routerName: default
      wildcardPolicy: None

/label qe-approved
thanks

openshift-ci-robot · 2024-12-06T06:59:26Z

@gcs278: This pull request references Jira Issue OCPBUGS-45290, which is valid.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target version (4.19.0) matches configured target version for branch (4.19.0)
bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @ShudiLi

In response to this:

Previously, only SHA1 leaf certs were rejected. However, in 4.16, any SHA1 cert that is CA-signed (not self-signed) is unsupported. This led to cases were routes with SHA1 intermediate CA certs were accepted, but HAProxy rejects them. Self-signed SHA1 certificates (i.e. root CA) remain supported since they are not subject to verification.

This update ensures all route certs, including the server, CA, and destination CA certs, are inspected, and any SHA1 cert that is not self-signed is rejected.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

ShudiLi · 2024-12-06T06:59:31Z

/retest-required

gcs278 · 2024-12-10T21:08:32Z

Andy offered to help review (thanks!)
/assign @frobware

candita · 2025-01-10T21:38:10Z

pkg/router/routeapihelpers/validation.go

+		// It's important that we do NOT reject self-signed certificates, as many root CAs still utilize SHA1.
+		if !isSelfSignedCert(cert) {
+			switch certs[0].SignatureAlgorithm {
+			case x509.SHA1WithRSA, x509.ECDSAWithSHA1:


What about DSAWithSHA1?

I originally left it out because DSA is unsupported by the router (DSA is deprecated), the router won't parse DSA certificate private keys:

router/pkg/router/routeapihelpers/validation.go

Lines 73 to 88 in 69f742b

switch t := key.(type) {

case *rsa.PrivateKey:

block = &pem.Block{

Type: "RSA PRIVATE KEY",

Bytes: x509.MarshalPKCS1PrivateKey(t),

}

case *ecdsa.PrivateKey:

block = &pem.Block{

Type: "EC PRIVATE KEY",

}

if block.Bytes, err = x509.MarshalECPrivateKey(t); err != nil {

return nil, err

}

default:

return nil, fmt.Errorf("block private key %T is not valid", key)

}

So providing any DSA server certificate & key results in:

Invalid value: "redacted key data": block PRIVATE KEY is not valid

If I try to use a DSA intermediate cert, it get something similar, presumably because the x509 GO library doesn't support verifying DSA certificates:

[spec.tls.certificate: Invalid value: "redacted certificate data": error verifying certificate: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: insecure algorithm DSA-SHA1" while trying to verify candidate authority certificate "www.exampleinter.com")

So, it looks like the router has always rejected certs using DSA keys. I can add a comment to document this.

Ok, so it is rejecting them properly so we know for sure a DSAWithSha1 (or any DSA) certificate doesn't break HAProxy router reload? Why not just add it here anyway?

Ok, so it is rejecting them properly so we know for sure a DSAWithSha1 (or any DSA) certificate doesn't break HAProxy router reload?

Right.

Why not just add it here anyway?

Yea, it's a fair question. I originally left it out simply because it was already unsupported. But it's a fair point that adding it here would provide a more precise error message about DSA-SHA1, so that's a argument for adding it. I'll update.

pkg/router/routeapihelpers/validation.go

pkg/router/routeapihelpers/validation_test.go

candita · 2025-01-10T22:23:13Z

@gcs278

In other words, is a self-signed cert okay to be ignored for a DestinationCACertificate or Certificate

DestinationCACertificate needs to allow SHA1 self-signed certs (a lot of root CAs use SHA1). So it is required for us to ignore self-signed certs in our SHA1 validation here.

As for Certificate, there isn't a critical business need to allow SHA1 self-signed leaf certs unlike DestinationCACertificate and CACertificate. But two thoughts:

I think the router should be accurate in what it's rejecting, and shouldn't reject things that HAProxy actually supports.

4.15 dev clusters (I hope not prod...) may be using self-signed SHA1 certs for testing. When they upgrade, we are currently forcing them to recreate all of them, even though 4.16 HAProxy supports them. Unnecessary upgrade pains for customers.
Open to other opinions.

I don't remember what this referred to and can't find the comment. What is the conclusion?

gcs278

Thanks @candita! Ready for another review.

pkg/router/routeapihelpers/validation.go

pkg/router/routeapihelpers/validation_test.go

gcs278 · 2025-01-14T04:12:44Z

pkg/router/routeapihelpers/validation.go

+		// It's important that we do NOT reject self-signed certificates, as many root CAs still utilize SHA1.
+		if !isSelfSignedCert(cert) {
+			switch certs[0].SignatureAlgorithm {
+			case x509.SHA1WithRSA, x509.ECDSAWithSHA1:


I originally left it out because DSA is unsupported by the router (DSA is deprecated), the router won't parse DSA certificate private keys:

router/pkg/router/routeapihelpers/validation.go

Lines 73 to 88 in 69f742b

switch t := key.(type) {

case *rsa.PrivateKey:

block = &pem.Block{

Type: "RSA PRIVATE KEY",

Bytes: x509.MarshalPKCS1PrivateKey(t),

}

case *ecdsa.PrivateKey:

block = &pem.Block{

Type: "EC PRIVATE KEY",

}

if block.Bytes, err = x509.MarshalECPrivateKey(t); err != nil {

return nil, err

}

default:

return nil, fmt.Errorf("block private key %T is not valid", key)

}

So providing any DSA server certificate & key results in:

Invalid value: "redacted key data": block PRIVATE KEY is not valid

If I try to use a DSA intermediate cert, it get something similar, presumably because the x509 GO library doesn't support verifying DSA certificates:

[spec.tls.certificate: Invalid value: "redacted certificate data": error verifying certificate: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: insecure algorithm DSA-SHA1" while trying to verify candidate authority certificate "www.exampleinter.com")

So, it looks like the router has always rejected certs using DSA keys. I can add a comment to document this.

gcs278 · 2025-01-14T14:50:22Z

I don't remember what this referred to and can't find the comment. What is the conclusion?

That thread is the first thread when I review the changes: https://github.com/openshift/router/pull/642/files#r1881050540. Does that link work for you?

gcs278 · 2025-01-14T18:38:57Z

/retest

candita · 2025-01-16T00:37:08Z

This is a suspicious error to see on this PR. Or is it coincidentally related to signing?

: [sig-imageregistry][Serial] Image signature workflow can push a signed image to openshift registry and verify it [apigroup:user.openshift.io][apigroup:image.openshift.io] [Skipped:Disconnected] [Suite:openshift/conformance/serial] expand_less 5m3s
{ fail [github.com/openshift/origin/test/extended/images/signatures.go:40]: Unexpected error:
<*errors.errorString | 0xc0019021a0>:
timed out while waiting of an image stream tag e2e-test-registry-signing-tnf9k/signer:latest
{
s: "timed out while waiting of an image stream tag e2e-test-registry-signing-tnf9k/signer:latest",
}

/test e2e-aws-serial

gcs278 · 2025-01-16T01:35:30Z

This is a suspicious error to see on this PR. Or is it coincidentally related to signing?

It does look funny, but according to search.CI, I see a lot of other instances of this failure for other PRs, so I think it's not related.

gcs278 · 2025-01-16T14:28:37Z

The issue with e2e-aws-serial appears to be a docker build failure:

  STEP 1/8: FROM image-registry.openshift-image-registry.svc:5000/openshift/cli
  STEP 2/8: ENV "BUILD_LOGLEVEL"="2"
  --> 763af0107730
  STEP 3/8: WORKDIR /var/lib/origin
  --> 47d2f4016f8f
  STEP 4/8: RUN source /etc/os-release     && rhel_major=${VERSION_ID%.*}     && yum config-manager     --add-repo "https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi${rhel_major}/${rhel_major}/\$basearch/baseos/os/"     --add-repo "https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi${rhel_major}/${rhel_major}/\$basearch/appstream/os/"
  ART yum/dnf wrapper [1]: Checking for CI build pod repo definitions...
  ART yum/dnf wrapper [1]: Did not detect that this script is running in a CI build pod. Will not install CI repositories.
  error: build error: building at STEP "RUN source /etc/os-release     && rhel_major=${VERSION_ID%.*}     && yum config-manager     --add-repo "https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi${rhel_major}/${rhel_major}/\$basearch/baseos/os/"     --add-repo "https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi${rhel_major}/${rhel_major}/\$basearch/appstream/os/"": while running runtime: exit status 6

/test e2e-aws-serial

Cluster installation failures that don't look specific to ingress:
/test e2e-upgrade

candita · 2025-01-16T20:46:52Z

pkg/router/routeapihelpers/validation.go

+			// Unsupported destinationCACertificates algorithms won't prevent HAProxy from starting.
+			// However, HAProxy will quietly refuse to use them at runtime. Rejecting here improves UX.
+			if err := validateCertSignatureAlgorithms(certs); err != nil {
+				result = append(result, field.Invalid(tlsFieldPath.Child("destinationCACertificate"), "redacted ca certificate data", err.Error()))


Why not add the SHA1 issue to the error message? Otherwise the user still won't know what's wrong with the CA certificate.

Yes, it is already added to the error message via the err return value from validateCertSignatureAlgorithms

candita · 2025-01-16T20:53:28Z

pkg/router/routeapihelpers/validation.go

+		x509.SHA384WithRSAPSS,
+		x509.SHA512WithRSAPSS:
+		return x509.RSA
+	case x509.DSAWithSHA1,


Why is it important to include DSA here and not in validateCertSignatureAlgorithms? If it wasn't included here I wouldn't have noticed it was missing in validateCertSignatureAlgorithms.

DSA was included here as a design choice because the function's responsibility is intended to be generic: signatureAlgorithmToPublicKeyAlgorithm, it's simply converting the known signature algorithms to a public key algorithm type, similar to a function you'd find a library. It doesn't make any assumptions or limitations about whether DSA is supported or not, which (in my opinion) makes this code safer to future reuse.

I've since added DSA SHA1 to the rejection list, so it's now we use it in both functions you referenced.

candita · 2025-01-16T21:12:03Z

pkg/router/routeapihelpers/validation.go

+			switch cert.SignatureAlgorithm {
+			// DSAWithSHA1 (as well as any DSA key algorithm) is already unsupported and rejected.
+			case x509.SHA1WithRSA, x509.ECDSAWithSHA1:
+				return fmt.Errorf("router does not support CA-signed certs using SHA1")


Why not collect/append the errors on the certs and return them all?

Ah sorry I think I missed this comment in an earlier review.

Yea I can update it. It's an edge case that multiple non-self-signed certs using SHA1 or MD5, but it's possible nonetheless, and the function should handle it.

candita · 2025-01-16T21:17:29Z

Still seeing this issue. Want to report it to TRT?

[sig-imageregistry][Serial] Image signature workflow [It] can push a signed image to openshift registry and verify it [apigroup:user.openshift.io][apigroup:image.openshift.io] [Skipped:Disconnected] [Suite:openshift/conformance/serial]
github.com/openshift/origin/test/extended/images/signatures.go:32

candita · 2025-01-16T21:17:55Z

/test e2e-aws-serial

Previously, only SHA1 leaf certs were rejected. However, in 4.16, any SHA1 cert that is CA-signed (not self-signed) is unsupported. This led to cases were routes with SHA1 intermediate CA certs were accepted, but HAProxy rejects them. Self-signed SHA1 certificates (i.e. root CA) remain supported since they are not subject to verification. This update ensures all route certs, including the server, CA, and destination CA certs, are inspected, and any SHA1 cert that is not self-signed is rejected.

gcs278

Thanks for another review @candita, comments posted

gcs278 · 2025-01-16T20:58:56Z

pkg/router/routeapihelpers/validation.go

+			// Unsupported destinationCACertificates algorithms won't prevent HAProxy from starting.
+			// However, HAProxy will quietly refuse to use them at runtime. Rejecting here improves UX.
+			if err := validateCertSignatureAlgorithms(certs); err != nil {
+				result = append(result, field.Invalid(tlsFieldPath.Child("destinationCACertificate"), "redacted ca certificate data", err.Error()))


Yes, it is already added to the error message via the err return value from validateCertSignatureAlgorithms

gcs278 · 2025-01-16T21:20:42Z

pkg/router/routeapihelpers/validation.go

+		// It's important that we do NOT reject self-signed certificates, as many root CAs still utilize SHA1.
+		if !isSelfSignedCert(cert) {
+			switch certs[0].SignatureAlgorithm {
+			case x509.SHA1WithRSA, x509.ECDSAWithSHA1:


Ok, so it is rejecting them properly so we know for sure a DSAWithSha1 (or any DSA) certificate doesn't break HAProxy router reload?

Right.

Why not just add it here anyway?

Yea, it's a fair question. I originally left it out simply because it was already unsupported. But it's a fair point that adding it here would provide a more precise error message about DSA-SHA1, so that's a argument for adding it. I'll update.

gcs278 · 2025-01-16T21:30:05Z

pkg/router/routeapihelpers/validation.go

+		x509.SHA384WithRSAPSS,
+		x509.SHA512WithRSAPSS:
+		return x509.RSA
+	case x509.DSAWithSHA1,


DSA was included here as a design choice because the function's responsibility is intended to be generic: signatureAlgorithmToPublicKeyAlgorithm, it's simply converting the known signature algorithms to a public key algorithm type, similar to a function you'd find a library. It doesn't make any assumptions or limitations about whether DSA is supported or not, which (in my opinion) makes this code safer to future reuse.

I've since added DSA SHA1 to the rejection list, so it's now we use it in both functions you referenced.

gcs278 · 2025-01-16T21:40:33Z

pkg/router/routeapihelpers/validation.go

@@ -205,6 +205,11 @@ func ExtendedValidateRoute(route *routev1.Route) field.ErrorList {
 			} else {
 				tlsConfig.CACertificate = string(data)
 			}
+			// HAProxy will fail to start if intermediate CA certs use unsupported signature algorithms.
+			// However, root CAs can still use unsupported algorithms since they are self-signed.


We are only checking the CACertificate here, and I think I was wondering about the other certs. So we specifically do not check the other certs in the tlsConfig variable for the reasons above.

Sorry, I'm a bit confused, we do check spec.tls.certificate here:

router/pkg/router/routeapihelpers/validation.go

Line 444 in 72201c5

if err := validateCertSignatureAlgorithms(certs); err != nil {

And we check spec.tls.destinationCACertificate here:

router/pkg/router/routeapihelpers/validation.go

Line 273 in 72201c5

if err := validateCertSignatureAlgorithms(certs); err != nil {

So we check every certificate provided equally (server cert, CACerts, and destinationCACerts), any certificate that HAProxy uses is subject the SHA1 rejection. Every type of cert gets the same treatment (e.g. self-signed Certs are exempt from SHA1 check).

Are we already doing point 2 or not?

We are currently doing point 2, by that I mean today we are unnecessarily forcing users to recreate/upgrade their self-signed SHA1 server certs in 4.15 before upgrading, when really HAProxy in 4.16 still allows/supports it (this PR will fix that).

gcs278 · 2025-01-17T00:05:40Z

pkg/router/routeapihelpers/validation.go

+			switch cert.SignatureAlgorithm {
+			// DSAWithSHA1 (as well as any DSA key algorithm) is already unsupported and rejected.
+			case x509.SHA1WithRSA, x509.ECDSAWithSHA1:
+				return fmt.Errorf("router does not support CA-signed certs using SHA1")


Ah sorry I think I missed this comment in an earlier review.

Yea I can update it. It's an edge case that multiple non-self-signed certs using SHA1 or MD5, but it's possible nonetheless, and the function should handle it.

gcs278 · 2025-01-17T00:24:41Z

Still seeing this issue. Want to report it to TRT?

[sig-imageregistry][Serial] Image signature workflow [It] can push a signed image to openshift registry and verify it [apigroup:user.openshift.io][apigroup:image.openshift.io] [Skipped:Disconnected] [Suite:openshift/conformance/serial]
github.com/openshift/origin/test/extended/images/signatures.go:32

I see someone posted about it slack and it seems like the image-registry team is aware of it and a recommendation has been made to fix it. I'll keep an eye on the progress.

openshift-ci · 2025-01-17T03:43:58Z

@gcs278: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-serial	`fb0668a`	link	true	`/test e2e-aws-serial`
ci/prow/okd-scos-e2e-aws-ovn	`fb0668a`	link	false	`/test okd-scos-e2e-aws-ovn`

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

openshift-ci-robot added the jira/severity-moderate Referenced Jira bug's severity is moderate for the branch this PR is targeting. label Dec 4, 2024

openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Dec 4, 2024

openshift-ci-robot added jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Dec 4, 2024

gcs278 force-pushed the reject-intermediate-sha1 branch from d2d10e7 to 36105f1 Compare December 5, 2024 20:17

gcs278 changed the title ~~[WIP] OCPBUGS-45290: Reject Intermediate Certs using SHA1~~ [WIP] OCPBUGS-45290: Reject All CA-Signed Certs Using SHA1 Dec 5, 2024

gcs278 force-pushed the reject-intermediate-sha1 branch 3 times, most recently from 6b47be2 to 7bb99ea Compare December 5, 2024 20:30

gcs278 changed the title ~~[WIP] OCPBUGS-45290: Reject All CA-Signed Certs Using SHA1~~ OCPBUGS-45290: Reject All CA-Signed Certs Using SHA1 Dec 5, 2024

gcs278 marked this pull request as ready for review December 5, 2024 20:41

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Dec 5, 2024

openshift-ci bot requested review from alebedev87 and frobware December 5, 2024 20:41

openshift-ci-robot added jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. and removed jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Dec 6, 2024

openshift-ci bot requested a review from ShudiLi December 6, 2024 02:28

openshift-ci bot added the qe-approved Signifies that QE has signed off on this PR label Dec 6, 2024

openshift-ci bot assigned frobware Dec 10, 2024

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation.go Outdated Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Outdated Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Outdated Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Outdated Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Outdated Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Outdated Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Outdated Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Outdated Show resolved Hide resolved

candita reviewed Jan 10, 2025

View reviewed changes

pkg/router/routeapihelpers/validation_test.go Outdated Show resolved Hide resolved

gcs278 force-pushed the reject-intermediate-sha1 branch from 69f742b to 72201c5 Compare January 14, 2025 14:38

gcs278 commented Jan 14, 2025

View reviewed changes

candita reviewed Jan 16, 2025

View reviewed changes

gcs278 force-pushed the reject-intermediate-sha1 branch from 72201c5 to fb0668a Compare January 17, 2025 00:14

gcs278 commented Jan 17, 2025

View reviewed changes

	switch t := key.(type) {
	case *rsa.PrivateKey:
	block = &pem.Block{
	Type: "RSA PRIVATE KEY",
	Bytes: x509.MarshalPKCS1PrivateKey(t),
	}
	case *ecdsa.PrivateKey:
	block = &pem.Block{
	Type: "EC PRIVATE KEY",
	}
	if block.Bytes, err = x509.MarshalECPrivateKey(t); err != nil {
	return nil, err
	}
	default:
	return nil, fmt.Errorf("block private key %T is not valid", key)
	}

OCPBUGS-45290: Reject All CA-Signed Certs Using SHA1 #642

Are you sure you want to change the base?

OCPBUGS-45290: Reject All CA-Signed Certs Using SHA1 #642

Conversation

gcs278 commented Dec 4, 2024 • edited Loading

openshift-ci bot commented Dec 4, 2024

openshift-ci-robot commented Dec 4, 2024

gcs278 commented Dec 6, 2024

gcs278 commented Dec 6, 2024

openshift-ci-robot commented Dec 6, 2024

gcs278 commented Dec 6, 2024

openshift-ci-robot commented Dec 6, 2024

ShudiLi commented Dec 6, 2024

openshift-ci-robot commented Dec 6, 2024

ShudiLi commented Dec 6, 2024

gcs278 commented Dec 10, 2024

candita Jan 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

candita commented Jan 10, 2025 • edited Loading

gcs278 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gcs278 commented Jan 14, 2025

gcs278 commented Jan 14, 2025

candita commented Jan 16, 2025

gcs278 commented Jan 16, 2025

gcs278 commented Jan 16, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

candita commented Jan 16, 2025

candita commented Jan 16, 2025

gcs278 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gcs278 commented Jan 17, 2025

openshift-ci bot commented Jan 17, 2025

gcs278 commented Dec 4, 2024 •

edited

Loading

candita Jan 10, 2025 •

edited

Loading

candita commented Jan 10, 2025 •

edited

Loading